r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

Somebody with more privilege than I must update the mirror at https://ci-mirrors.rust-lang.org/rustc/ to include https://download.freebsd.org/ftp/releases/amd64/12.2-RELEASE/base.txz and https://download.freebsd.org/ftp/releases/i386/12.2-RELEASE/base.txz .

Hey! So I tried to read the discussion in #89058, but I admit I am not entirely following the picture here or what this change implies for Rust. Currently, it seems like our platform support docs leave out the FreeBSD version that we're targeting, which seems like an oversight -- presumably, we should provide something similar to the Linux builders, though I am not familiar with how FreeBSD's versioning works (e.g., do we want to specify the kernel version? libc version? Is that the same?)

We don't currently have a set of target maintainers on file for FreeBSD -- perhaps @asomers you and @bdrewery might be interested in signing up for that? There's some more details in what this entails in the target tier policy; I think FreeBSD on x86_64 is at Tier 2 with host tools right now.

If I'm following #89058 (comment) correctly, then it sounds like accepting the bump to the compiler environment used on our FreeBSD builders will not affect the compatibility of rustc or std with older versions of FreeBSD (i.e., the binaries we ship will still run out of the box on FreeBSD 11 or 10). Is that right? This would be different from how our compatibility story works on e.g. linux targets, where we need to build in an environment with an old glibc toolchain set in order to maintain compatibility.

Hey! So I tried to read the discussion in #89058, but I admit I am not entirely following the picture here or what this change implies for Rust. Currently, it seems like our platform support docs leave out the FreeBSD version that we're targeting, which seems like an oversight -- presumably, we should provide something similar to the Linux builders, though I am not familiar with how FreeBSD's versioning works (e.g., do we want to specify the kernel version? libc version? Is that the same?)

Kernel and libc version are the same, and there's little point to supporting a specific minor version. We should just specify the minimum supported major version.

We don't currently have a set of target maintainers on file for FreeBSD -- perhaps @asomers you and @bdrewery might be interested in signing up for that? There's some more details in what this entails in the target tier policy; I think FreeBSD on x86_64 is at Tier 2 with host tools right now.

I can ask around. What are the responsibilities of a target maintainer?

If I'm following #89058 (comment) correctly, then it sounds like accepting the bump to the compiler environment used on our FreeBSD builders will not affect the compatibility of rustc or std with older versions of FreeBSD (i.e., the binaries we ship will still run out of the box on FreeBSD 11 or 10). Is that right? This would be different from how our compatibility story works on e.g. linux targets, where we need to build in an environment with an old glibc toolchain set in order to maintain compatibility.

This PR alone definitely won't affect the usability of libc on FreeBSD 11. I'm not sure about the toolchain itself; I don't know enough about how rustc is built.

I can ask around. What are the responsibilities of a target maintainer?

There's no concrete list, but generally it's doing the educational work with rustc/std maintainers for PRs like this one or updates to the standard library, as well as keeping an eye on Rust's story on that target (e.g., if there is some new tooling or whatever, letting us know or doing the work to add support in rustc/std). It's also totally fine for these folks to step back, but current policy is that if they're needed and not available we may drop the target.

Ideally these folks are also regularly running the test suite (e.g., once a month or so) on tier-2-with-host-tools or lower targets, primarily to ensure that the target still works OK and to file issues for and fix any broken tests.

This PR alone definitely won't affect the usability of libc on FreeBSD 11. I'm not sure about the toolchain itself; I don't know enough about how rustc is built.

Can you say more about what you would need to know? I'm happy to clarify things or help investigate, but without more information I am hesitant to land this patch since it seems plausibly likely to break users. (Of course, some indications are that not doing this also will...)

I need to know whether the toolchain's build process links any symbols according to the build host's installed libc, or if it just uses the symbol versions defined in rust's libc. I'm not sure what that's called in compiler-speak. I suppose I could just try it and find out. If I build the toolchain locally, is there an easy way to run its test suite on a host other than the one that built it?
Oh, and where are target maintainers recorded? I can't find it in the repo anywhere.

Oh, and where are target maintainers recorded?

Here is an example: https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/x86_64-unknown-none.md.

Ping from triage:
@asomers can you please post the status of this PR?

@JohnCSimon still waiting for somebody to upload the FreeBSD release files. They should be named something like
https://ci-mirrors.rust-lang.org/rustc/2020-08-09-freebsd-{amd64,i386}-12.2-RELEASE-base.txz . I don't have the permission to do it myself. However, this PR has lingered so long that release 12.3 is now expected in a matter of days.

I'm happy to take care of uploading artifacts, but I don't think we've yet resolved the questions around what the implications for this change are for users, so we're not quite at the stage where that would unblock us from what I can tell.

I need to know whether the toolchain's build process links any symbols according to the build host's installed libc, or if it just uses the symbol versions defined in rust's libc. I'm not sure what that's called in compiler-speak. I suppose I could just try it and find out. If I build the toolchain locally, is there an easy way to run its test suite on a host other than the one that built it?

There's not a great way to run tests on a different host, though I suppose it should mostly work to copy the directory (so long as all paths are the same) as a whole to a different host. That would need the target/host triples to match though.

As FreeBSD 11 is EOL for about half a year now, and FreeBSD is a tier 2 target, I think we can go ahead here even if it does break rustc on FreeBSD 11 completely.

As FreeBSD 11 is EOL for about half a year now, and FreeBSD is a tier 2 target, I think we can go ahead here even if it does break rustc on FreeBSD 11 completely.

triage: assigning to reviewer.
@rustbot label: -S-waiting-on-author +S-waiting-on-review

Yeah, it's probably OK to move ahead with this. Can someone provide links to the right files to upload, and then I can do that and approve this PR?

@Mark-Simulacrum use https://download.freebsd.org/ftp/releases/amd64/12.3-RELEASE/base.txz and https://download.freebsd.org/ftp/releases/i386/12.3-RELEASE/base.txz .

ping @Mark-Simulacrum could you please upload those files?

https://ci-mirrors.rust-lang.org/rustc/2022-05-06-freebsd-12.3-amd64-base.txz and https://ci-mirrors.rust-lang.org/rustc/2022-05-06-freebsd-12.3-i386-base.txz

For the future, @rustbot ready. will update labels so that PRs get in reviewers' queues and folks can take a look at them more quickly.

Closing this in favour of #97944